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(SD) to a service provider (20) over the public network (100), together with card application data (CAD) generated by a smart card (18). 
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SECURE TRANSACTION SYSTEM 

Technical Field 

The present invention relates to a secure transaction system, particularly for use 
over a public network. 
Background Art 

The most common and well-known public data network is the Internet, which 
provides network access to members of the public at low cost. Many types of commercial 
transaction which were previously conducted via telephone, mail or private network may 
now be conducted more easily over the Internet. However, internet protocols such as 
TCP/IP were not designed for security, and it has therefore been necessary to provide 
additional protocols for secure transactions over the Internet, including transport-level 
protocols such as the Secure Sockets Layer (SSL), and application-level protocols such as 
the Secure Hypertext Transfer Protocol (SHTTP). Such protocols aim to prevent 
interception, decryption and forgery of transactions between a client and a server over the 
Internet, but they do not verify the identity of the user of the client terminal. For example, 
in a credit card transaction, only the user's name and address, and the card number and 
expiry date need be supplied to order goods or services over the Internet. It is 
comparatively easy to obtain the necessary information to carry out fraudulent transactions 
over the Internet. Some verification of the user's identity is usually implemented at the 
application level, such as the use of passwords, but these too can be obtained or guessed. 

Nevertheless, various protocols have been proposed for allowing secure 
transactions, and particularly secure payment, over the Internet; one example is Secure 
Electronic Transaction (SET), a protocol for credit card transactions over the Internet, a 
modification of which is described in WO 97/41539. Typically, such transactions involve 
three parties: a client which supplies credit card details, a service provider server operated 
by a supplier of goods or services, and an authorisation server which checks the credit card 
details and informs the service provider server whether payment is authorised by the 
operator of the credit card system. 

However, conventional electronic transaction systems do not support non- 
repudiation; in other words, they do not provide sufficient evidence to confirm that a 
specific transaction was authorised. 
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Moreover, conventional electronic transactions do not bind a specific user to the 
use of an authorisation card. 

Furthermore, conventional electronic transaction systems are limited in their 
application, because the authorising server is designed merely to give an authorise or 
decline message on the basis of the details supplied. 

Statement of the Invention 

According to one aspect of the present invention, there is provided an electronic 
transaction system in which a terminal combines transaction data which is unique to a 
current transaction with terminal data which is unique to that terminal to generate bound 
terminal/transaction information which is sent to the transaction server. The transaction 
server sends the transaction data to an authorisation server which returns information 
which binds the transaction to the identity of the authorisation server. The transaction 
server then has available information which binds together the transaction, the terminal and 
the authorisation server in a form which cannot be fraudulently created by the transaction 
server, and therefore cannot be repudiated. 

According to another aspect of the present invention, there is provided an electronic 
transaction system in which an authorisation token is issued to a user. Information 
confirming the identity of both the authorisation token and the user are presented to an 
authority which confirms the validity of this information and makes it available to an 
authorisation server. The authorisation token is then used in an electronic transaction with a 
transaction server, in which user identification information and authorisation token 
information are supplied to the transaction server and passed to the authorisation server. 
The authorisation server compares the user identification information and authorisation 
token information with information previously made available by the authority and 
indicates to the transaction server the result of the comparison. In this way, because the 
correspondence between the user and the token has been verified before the transaction, the 
use of the token by the user can be confirmed during the transaction. 

According to a further aspect of the present invention, there is provided an 
electronic transaction system in which a user terminal transmits to a transaction server 
transaction data and identification data. The transaction data is passed from the transaction 
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server to an authorisation server, which compares the identification data with stored 
identification data relating to authorised users of the system. The authorisation server then 
transmits to the transaction server an authorisation message indicating how the 
identification data matches with the stored identification data. The transaction server 
determines whether to accept the transaction data on the basis of the authorisation message 
and the transaction data. 

Brief Description of the Drawings 

Specific embodiments of the present invention will now be described with 
reference to the accompanying drawings, in which: 

Figure 1 is a diagram of the service functions of an authorisation system in an 

embodiment of the present invention; 

Figure 2 is a diagram of the architecture of the system: 

Figure 3 is a diagram of the hardware components of a user terminal; 

Figure 4 is a diagram of the hardware components of a smartcard; 

Figure 5 is a diagram of the sub-systems within the authorisation server in the 

embodiment; 

Figure 6 is a diagram of the certification architecture of the system; 

Figure 7 is a diagram illustrating a more specific embodiment in which the system 

is used to authorise an electronic form; 

Figure 8 shows the flow of data in the specific embodiment; 

Figure 9 shows the cryptographic processes applied by the user terminal; 

Figure 10 shows the digital signature validation process applied by the electronic 

form server; 

Figure 1 1 shows the transmission of an authorisation request message to the 
authorisation server; 

Figure 12 shows the authorisation process performed by the authorisation server; 
and 

Figure 13 shows the authorisation response message process from the authorisation 
server to the electronic form server. 
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Modes for Carrying Out the Invention 

Authorisation Service 

Figure 1 shows the service functions which provide a digital signature generation 
and authentication service in an embodiment of the present invention. A digital signature 
generator 10 generates digital signatures in the form of data which uniquely identifies a 
specific party and binds the signed data to that party. Digital signatures are a known 
technique for protecting data from modification and for identifying the signing party. The 
signing party is provided with a private/public key pair, which can be used to generate and 
verify digital signatures. The 'party' is usually assumed to be the user operating the 
computer which stores the private key and generates the digital signature. However, in the 
present embodiment, the private key is stored on a smart card and therefore the digital 
signature binds the signed data to the smart card. Hence, the 'party 7 is the smart card. 

As is well-known, data encrypted with a private key can be decrypted with the 
corresponding public key, and vice versa. Suitable cryptographic algorithms include the 
RSA algorithm, described for example in US 4,405,829. In a typical digital signature 
process, the data to be 'signed 5 is subjected to a hash algorithm, such as the Secure Hash 
Algorithm (SHA). The result is a type of checksum, known as a 'hash", which depends 
both on the values of the bits making up the data and the positions of those bits. It is 
therefore very difficult to modify the data while giving the same hash. The hash is then 
encrypted using the private key, to produce a digital signature. 

A digital signature can be verified by performing the same hash algorithm on the 
received data as was used to generate the hash encoded in the digital signature. The digital 
signature is then decrypted using the public key and the decrypted hash is then compared to 
the calculated hash. If the hashes match, the signature is valid. 

Examples of digital signature algorithms are the RSA digital signature, in which the 
hash is encrypted together with an indication of the type of . the hash algorithm using RSA 
encryption, and the digital signature algorithm (DSA), in which the hash algorithm is the 
SHA and the hash is encrypted together with a random number by a variant of the Diffie- 
Helman algorithm. 



WO 99/64995 



PCT/GB98/02868 



5 

The digital signature generator 10 exchanges information IE with a digital signature 
acceptor 20. and sends 'signed' information SI to the digital signature acceptor 20 which 
includes a first digital signature generated using a private key and a second digital 
signature using a symmetric key, both keys being held by the digital signature generator 
5 10. On receipt of the signed information, the digital signature acceptor 20 verifies the first 
signature and sends an authorisation request AREQ to a digital signature authoriser 30. The 
authorisation request AREQ includes information derived from the signed information SI 
and the second signature. The digital signature authoriser 30 checks the information 
derived from the signed information SI and the second signature, and sends to the digital 
10 signature acceptor an authorisation response ARES indicating whether the signature is to 
be accepted as genuine. The authorisation response ARES is signed with a digital signature 
generated by a private key held by the digital signature authoriser 30. Dependent on the 
authorisation response, the digital signature acceptor 20 then accepts or rejects the signed 
information SI. 

15 In order to provide evidence of the provision and acceptance or rejection of the 

signed information, the digital signature acceptor 20 may further transmit a notarisation 
request NREQ to a signed message notariser 40, including information derived from the 
signed information SI and from the authorisation response ARES. In response, the signed 
message notariser 40 transmits to the digital signature acceptor 20 a notarisation 

20 confirmation NCF which includes information derived from the notarisation request 

NREQ. digitally signed by the signed message notariser 40. The digital signature acceptor 
20 transmits archive deposit information ARDEP, which may for example comprise the 
signed information SL the authorisation response ARES and the notarisation confirmation 
NCR to a long-term archive 50. This information is later retrieved from the long-term 

25 archive 50 as archive retrieval information ARRET in the event of repudiation of the 
signed information SI. 

Optionally; where an independent time reference is needed, for example to confirm 
the exact time of a transaction such as the sending and receipt of the signed information SI, 
information from a standard time signal source 60 is made available to each of the 

30 functions described above and is incorporated in each digitally signed message. 
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Svstem Architecture 

A high-level system architecture of the digital signature authorisation service is 
shown in Figure 2. Like parts to those of Figure 1 carry the same reference numerals. 

A user 12 wishing to subscribe to the digital signature service must first apply for a 
smart card 18 from which the user's digital signatures are derived. The user 12 has a 
computer 14 connectable to the Internet 100 via a modem 16, using for example web 
browser software and TCP/IP protocols as is well-known in the art. 

The components of the computer 14, which may be an IBM-compatible 'personal 
computer' or Apple Macintosh computer, are shown in Figure 3. A CPU 1 10 is connected 
through a bus 120 to main memory 130, a disc controller 140 connected to a hard disc 145, 
a user interface controller 150 connected to a keyboard 152 and other input devices such as 
a mouse 154, a display controller 160 connected to a visual display 165, and an I/O 
controller 1 70. The I/O controller 1 70 controls the modem 1 6 and a card reader 1 74 into 
which a smart card can be docked. Optionally, a biometric device 1 80 is connected to the 
I/O controller 170 or to the user interface controller 150. The biometric device 180 may be 
a fingerprint scanner, an iris scanner, or another device which allows information derived 
uniquely from the user 12 to be input to the .computer 14. The fingerprint scanner may be 
integrated with the keyboard 1 52. 

The user accesses a customer server 70 through the Internet 100 and requests 
subscription to the digital signature service. The request is passed on to a card bureau 90 by 
a suitable form of secure communication. The card bureau 90 sends a smart card 18 to the 
user 12. An example of the components within the smart card 1 8 is shown in Figure 4. 

The smart card 1 8 contains a processor 200 connected to a memory 2 1 0 and an 
external connector 220. The card 1 8 may include a power source such as a cell integrated 
within the card 1 8, or power may be supplied through the connector 220 by the card reader 
1 74. At least part of the memory 210 is non- volatile so that a operating program and data 
are stored when the card 18 is removed from the reader 174. . 

A public/private key pair and a card identity code are recorded in the non-volatile 
memory of the card 18 during manufacture. The private key is protected from being read 
from the card by an operating system running on the processor 200 and optionally by 
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hardware protection measures which prevent the non-volatile memory from being 
physically examined to determine its content. 

When a request is received from the customer server 70 ? the name of the user 12 is 
printed on the card 18, which is then sent to the user 12. A status message is sent to the 
authorisation server to indicate that the card 1 8 is issued but inactive. 

The user 12 then takes the card 18 to the public premises 80 of an organisation 
which supports the digital signature service, where the user's identity is checked against 
the identity of the user to whom the card 1 8 has been issued. Once the user's identity has 
been verified, a status message V is sent from the premises 80 to a card management server 
38 connected to the authorisation server 30, the message identifying the card 18 and the 
user 12, The user 12 is also issued with the card reader 174 and application software for the 
digital signature service, if the user 12 does not already have these. 

A PIN is recorded in the card 1 8 either before being issued to the user, or by the 
user the first time the card 18 is used in a transaction. In the former case, the user is 
notified of the PIN after the identity verification has taken place. 

To use the digital signature service, the user 12 inserts the card 18 into the card 
reader 174. Application software running on the computer 14 then prompts the user 12 for 
a PIN. The user enters a PIN which is compared to that stored on the card 1 8, and the 
application generates a card validation result (VR) which indicates whether a PIN has been 
requested and whether the entered PIN matched that stored on the card 18. 

Additionally or alternatively, the computer 14 obtains biometric data from the 
biometric device 180 if this is present. The smartcard 18 generates a digital signature for 
the signed information SI transmitted by the computer 14 to the service provider 20, as will 
be described in a specific example below. 

The service provider 20 may comprise a general purpose computer running web 
server software and connected to the Internet 100. The service provider 20 also runs 
authorisation software for communication with the authorisation server 30. 

The authorisation server 30 comprises a general purpose computer running 
authorisation server software and connected to the Internet 100. As shown in Figures 2 and 
5. the authorisation server 30 is also connected, for example over a local or private 
network, to a public key server 32. a card authentication server 34 and a customer 
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verification server 36. The public key server 32 and the card authentication server 34 
comprise dedicated hardware modules including encryption /decryption acceleration 
hardware. The customer verification server 36 stores a database containing the details of 
authorised users of the digital signature service. 

The authorisation server 30 receives from the service provider 20 the authorisation 
request AREQ, which includes a hash H of the signed information SI, a public key 
certificate, identification information relating to the card 18 and the user 12, and card 
authentication information. The authorisation server 30 sends the card authentication 
information CCHK to the card authentication server 34, which checks the authenticity of 
the card 1 8 and returns a response CRES indicating whether the card is authentic or not. 
The authentication server 30 sends the user identification information ID to the customer 
verification server 36, which returns a response IDRES indicating whether, or to what 
extent, the customer identity details are correct. 

The authorisation server 30 generates from the responses CRES and IDRES an 
authorisation message AM. which is sent to the public key server 32. The public key server 
32 signs the authorisation message AM to produce a signed authorisation response ARES 
which is transmitted to the service provider 20. 

Public Kev Hierarchy 

The digital signatures are generated, verified and authorised using public key 
cryptography, as explained above. The public keys are distributed by means of public key 
certificates, so that users of public keys can trust that the public keys belong to the parties 
with which the users wish to communicate. As is well known, a public key certificate 
consists of a name identifying a party who holds a private key (in this case, the card 18), 
the corresponding public key, and a digital signature comprising a hash of the name and the 
public key, encrypted using the private key of a certification authority trusted by the user. 
If the user does not have the certification authority's public key, this can be obtained from 
the certification authority's public key certificate, which is signed by a root certification 
authority. Thus, a hierarchy of public key certificates may be used, ultimately administered 
by a root certification authority which is always trusted. 
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If a public/private key pair is changed, however, the public key certificate is no 
longer valid. The old public key certificate may be revoked by placing a code identifying 
that certificate on a Certificate Revocation List CRL, which is circulated periodically to 
users of the public key. Before a public key certificate is used, it may first be checked 
against the CRL. 

Figure 6 shows the hierarchy of keys in the present embodiment. The smartcard 1 8 
performs the digital signature process using a private key SCK stored within the card 18. 
The corresponding public key is contained within a smart card certificate SCC stored 
within the card and signed using a card certification private key CCK of a card certification 
authority 110. The corresponding public key is contained within a card certification 
authority certificate CCC which is signed by a root certification authority private key RCK 
of a root certification authority 120. The root certification authority private key RCK is 
also used to sign the public key certificate ASC of the authorisation server 30. The 
corresponding public key is distributed in a root certification authority public key 
certificate RCC, which is self-signed using the corresponding private key RCK. The 
authorisation server private key ASK is used to provide a digital signature on the 
authorisation response ARES. 

Card Authentication 

In addition to the public key transactions described above, the smart card 18 also 
performs a symmetric key card authentication function with the authentication server 30. 
using a separate private key stored on the card 1 8. The process uses a two-key triple data 
encryption standard (DES, encrypt-decrypt-encrypt) algorithm in Cipher Block Chaining 
Mode to produce an eight byte message authentication code (MAC). 

The symmetric key authentication function is used for secure communications 
between the smartcard 18 and the authentication server 30, which the service provider 20 
passes transparently but is unable to decrypt. For each card authentication transaction, the 
MAC is calculated from a combination of: data stored internally in the card 18. including a 
variable application transaction counter value ATC which is incremented for each 
transaction, and a card identity number N which is included in the public key certificate 
SCC; data supplied by the service provider 20, including the time, date and the identity of 
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the service provider, so as to bind the MAC to the specific transaction; a hash H of the 
signed information SL so as to bind the MAC to the data supplied and to the digital 
signature; the validation result VR or information derived from the biometric data, and the 
second unpredictable number UN2. 

Electronic Forms Implementation 

A more specific embodiment will now be described with reference to Figures 7 to 
1 3. in which the digital signature system is used to authenticate a completed form supplied 
electronically by the user 12 to the service provider 20, which is in this case operated by a 
government department. For convenience. Figures 7 to 13 show the topological connection 
between the computer 14 and the service provider 20, and between the service provider 20 
and the authorisation server 30, as being through separate networks but in this example the 
connections are both through the Internet. 

Figure 8 shows the data transmission which takes place during a transaction. The 
computer 14 has already established an Internet connection to the service provider 20, and 
is running web browser software. In response to a request initiated by the user 12, the 
service provider 20 sends data D comprising HTML pages representing a blank form (such 
as a form for registering a new business). The user 12 completes the form by entering data 
within the browser software and requesting submission of the completed form to the 
serv ice provider 20. The browser software supports the digital signature service, for 
example by means of a 'plug-in" which modifies standard browser software, so that the 
user 12 is prompted to enter a PIN when requesting submission of the completed form. If 
the smartcard 1 8 is not located in the card reader 1 74, the software prompts the user 12 to 
do this. 

At a data processing stage DP, the smartcard 1 8 generates a digital signature from 
the form data F of the completed form and the smart card private key SCK. The signed data 
SD is then sent to the service provider 20, which verifies the signature by recovering the 
card public key from the smart card certificate SCC using the card certification public key 
recovered from the card certification authority certificate CCC, recalculating the hash 
function for the form data and comparing the recalculated hash function with the one 
signed with the smart card key SCK and included in the signed data SD. Signature 
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verification data SVD derived from the signed data SD is sent by the service provider 20 to 
the authorisation server 30. 

Card authentication data CAD ? which comprises the MAC and the input data used 
to generate the MAC, and the user identification data ID are transmitted to the service 
provider 20 and passed to the authentication server 30. The user identification data ID 
comprises for example the name, address and date of birth of the user, entered by the user 
12 and transmitted by the browser software in a separate field from the signed data SD. 
Optionally, biometric data from the biometric device 180 is included in the user 
identification information. Collectively, the signature verification data SVD. the card 
authentication data CAD and the user identification data ID comprise the authorisation 
request AREQ submitted to the authorisation server 30. 

The authorisation server 30 checks the authorisation request AREQ for counterfeit 
or replayed cryptograms, checks whether the smartcard public key certificate SCC matches 
the card identity and checks the user identification data ID against an entry in a database of 
details of known cardholders. The authentication server also verifies the MAC against the 
input data used to generate the MAC, using the appropriate symmetric key. The results of 
these checks are digitally signed using the authorisation server private key ASK and sent as 
the authorisation response ARES to the service provider 20. 

Some of the above processes will now be explained in greater detail. 

User to Service Provider 

Figure 9 shows how the data sent from the user's computer 14 to the service 
provider 20 is generated. The data D sent from the service provider 20 includes two 
random or otherwise unpredictable 32-bit numbers UNI and UN2, the date and time of the 
transaction and a server identifier SID. The first unpredictable number is embedded in the 
HTML form as a readable serial number and is returned in the form data F. 

The application software calculates a hash of the completed form data F using a 
secure hash algorithm SHA and sends the hash to the card 1 8, together with the second 
unpredictable number UN2 ? validation result VR, the date and time and the server 
identifier SID ? for use in the DES encryption process to generate the MAC. The card 
generates an application transaction counter value ATC which is also input to the DES 
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process. The hash is also supplied as an input to an RSA public key encryption process. 
The card public key certificate SCC is stored in the card 1 8 and is retrieved by the 
application software together with the MAC and signature data SD, for transmission to the 
service provider 20. 

5 

Signature Validation 

The process performed by the service provider 20 to validate the signature of the 
signed data SD is shown in Figure 10. The service provider 20 receives the form data F and 
checks (S10) that the serial number UNI matches that of the blank form previously sent. A 

1 0 hash is calculated from the form data F using the same SHA as performed by the card 1 8. 
The card public key is retrieved from the card public key certificate SCC and is used to 
decrypt (S20) the signature data SD to extract the hash calculated by the user's computer 
14. The two hashes are compared (S30) and the signature is validated if they match. 
However, this process only establishes that the form was digitally signed using the card 18. 

15 The service provider 20 must further check that the card 1 8 is valid and is being used by 
the authorised cardholder, as will be described below. 

Authorisation Request 

The service provider 20 sends the following information to the authorisation server 

20 30 in the authorisation request message ARES, as illustrated in Figure 1 1 : the user 
identification data ID, including any biometric data, the second unpredictable number 
UN2. the hash H calculated from the received form data F, the card public key certificate 
SCC. the validation result VR. the application transaction counter ATC and the message 
authentication code MAC. The form of the authorisation request message is shown in detail 

25 in Table 1 below: 

Table 1 - Authorisation Request Message 



Field Name 


Field Description 


Version 


Version of the Authorisation Request Message 


Service Provider Ref. 


Message reference supplied by service provider 


Authorisation Service 


Authorisation service reference supplied by the 
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Ref. 


service provider 


Contract Info 


A URL for a contract governing the use of the 
authorisation service 


Request Sent Time 


The time, as supplied by the service provider 
system clock, at which the message was 
transmitted 


sec 


Public key certificate of the card 18 


H 


Hash of the form data F 


User Time 


The time, from the user's computer 14. at which 
the authorisation request was transmitted from the 
computer 14 


Service Provider 
Identity 


Service provider identity used for generation of 
the MAC 


UN2 


Second unpredictable number 


Card Data 


Data generated by the application and the card 1 8 
and passed to the authorisation server , 


User Surname 


User s surname 


User First Name 


User s first name(s) 


User Title 


User s title 


User DOB 


User s date of birth 


User Address 


First line of user's address 


User Postcode 


User s postcode 



The Card Data described in Table 1 comprises the fields shown below in Table 2: 
Table 2 - Card Data Structure 



Field Name 


Field Description 


Cryptogram Info Data 


Indicates the type of the cryptogram 


Cryptogram Version Number 


Version number of the cryptogram 


Application Transaction Counter 


A counter value, stored in the card 
18, which is updated after each 
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transaction 


MAC 


Cryptogram generated by the card 18 


VR 


Validation Result 


Derivation Key Index 


Index which identifies the symmetric 
key to the authorisation server 30 



Authorisation Request Process 

The authorisation server 30 determines the authorisation response ARES as 
illustrated in Figure 12. The user identity information ID is sent to the customer 
verification server 36, which checks whether this information matches stored user identity 
information related to the card number, and returns a response IDRES indicating whether 
these details are correct and the status of the card. The card authentication data CAD are 
sent to the card authentication server 34 where the MAC is verified using the card number 
N, extracted from the card public key certificate, the second unpredictable number UN2 
and the date, time and server identity originally provided by the service provider 20. The 
card authentication server 34 also checks the validation result VR, determines whether the 
cryptogram has been replayed or the card counterfeited, and whether the card public key 
certificate SCC is valid and corresponds to the MAC. 

Optionally, the customer verification server 36 stores a database of biometric 
information for each authorised user, and the response IDRES includes information on the 
confidence level with which biometric data contained within the user identity information 
ID matches the stored profile for that user. 

Authorisation Response 

The authorisation server 30 formats the authorisation response message ARES and 
transmits it to the service provider 20 by means of a process illustrated in Figure 13. First, 
an authorisation message AM is generated including the following information: the hash 
value H and the user identification information ID copied from the authorisation request 
AREQ, and a response code indicating the card authentication and user verification server 
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responses. This message AM is sent to the public key server 32 which generates a digital 
signature for the message using the authorisation server private key ASK and returns this 
signature AS together with the authorisation server public key certificate ASC. The 
authorisation server then sends the authorisation message AM. the signature AS and the 
5 authorisation server certificate ASC to the service provider 20. together with a reference 
code indicating the agreement under which the authorisation is made to the service 
provider 20. 

The data content of the authorisation message is summarised below in Table 3: 
Table 3 - Authorisation Message Contents 



Field Name 


Field Description 


Service Provider Reference 


Message reference number supplied by the 
service provider, copied from the authorisation 
request message 


Hash 


Hash of the authorisation request message 


Request Received Time 


The time, from the authorisation server, at 
which the authorisation request was received 


Authorisation Response 


Authorisation Response Data 


Response Sent Time 


Time, from the authorisation server, at which 
the response was sent 



10 



The Authorisation Response Data is coded as individual bits, as shown in Table 4: 
Table 4 - Authorisation Response Data Bit Meaning 



Index 


Bit No. 


Meaning 


0 


0 


Card does not exist 




1 


Card not activated 




2 


Card expired 




3 


Card reported lost 




4 


Card reported stolen 




5 


Could not verify 




6 


Card registered as demo 
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7 


Verification error - see following bytes 


1 


0 


Unspecified address match failure 




1 


Surname did not match 




2 


First name did not match 




3 


Title did not match 




4 


Date of birth did not match 




5 


First line of address did not match 




6 


Postcode did not match 




7 


(Unused) 


2 


0 


Unspecified authentication failure 




1 


Card authentication could not be performed 




2 


Cryptogram verification failure 




3 


Application Transaction Counter value invalid 




4 


PIN verification not performed 




5 


PIN verification failed 



Optionally, the authorisation response data may include an indication of the 
confidence level with which the biometric data included in the customer identification 
information matches that stored in the customer verification server 36; for example. 
5 pattern matching algorithms used in iris and fingerprint scans will return a suitable value 
based on the correlation between an input and a reference pattern. 

On the basis of the authorisation response ARES, and the result of the signature 
verification process, the service provider 20 determines how the form data F is to be 
processed. For example, if the signature is verified and the transaction authorised by the 
10 authorisation server, the service provider may update a record corresponding to the user 12 
to add the information included in the form data F. If either the signature is not verified, or 
the transaction not authorised, the form data F may be discarded and/or a message 
transmitted to the user's computer indicating that the form has not been accepted. 

Since the authorisation response ARES contains detailed information about the 
1 5 results of the various authorization checks, the service provider may allow certain types of 
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transaction to proceed even if some of the authorization checks are indicated as 
unsuccessful. For example, if the title did not match, the service provider judges this as 
insignificant, since the user is unambiguously identified by other data, and the transaction 
is processed as acceptable by the service provider 20. 

In the option where the authorisation response ARES includes an indication of the 
confidence level with which the supplied user identification information ID matches the 
stored user identification information, the service provider 20 sets a minimum confidence 
level for the current transaction and allows the transaction to proceed if this confidence 
level is exceeded. Preferably, this minimum confidence level is determined according to 
the monetary value of the transaction, or if the transaction does not have a specified 
monetary value, the consequences of fraud in that transaction. 

Preferably, in the case of fraud, the authorisation response ARES is used to 
determine the liability between the operator of the service provider 20 and the operator of 
the authorisation server 30. For example, if any of the bits with index 0 are set, the 
authorisation server operator will not accept any liability if the service provider accepts the 
transaction, but if only one of the bits with index 1 is set. the authorisation server operator 
will accept liability only to a prearranged limit, and if none of the bits is set, the 
authorisation server operator will accept liability to the maximum value prearranged for the 
user 12. 

The present invention is not limited to the use of the Internet but may also be 
applied to transactions over other networks which are not inherently secure. The network 
used to connect the user's computer 14 to the service provider 20 may be separate from 
that used to connect the service provider 20 to the authorisation server 30. 

Although the above embodiment is described with reference to one specific user, it 
is evident that similar procedures are carried out for different users so that the system can 
perform transactions initiated by any one of a large number of users. 

The present invention is not limited to any specific type of transaction such as the 
authentication of forms or the authorisation of payment. 

In an alternative embodiment, the smart card 1 8 may sign the form data using the 
symmetric encryption key under the DES process and may dispense with the RSA 
encryption process. The service provider 20 will not then be able to verify the signature, 
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but instead recalculates the hash and transmits this to the authorisation server 30 for 
verification. 

In an alternative embodiment, the smart card 1 8 uses the private key SCK both to 
produce the MAC and to sign the form data F and does not use any symmetric encryption 
5 key. In that case, the service provider 20 checks the card application data CAD using the 
public key contained in the smartcard key certificate SCC to ensure that the MAC was 
generated from the input data using the private key SCK. However, the service provider 20 
is unable to check whether card specific data such as the application transaction counter 
ATC and the card number N are correct and correspond to a valid card, so that this card 
1 0 specific data is still sent to the authorization server 30, which checks the consistency of the 
card specific data and the validity of the card 1 8. Likewise, the user identification data ID 
is still sent to the authorization server 30 for comparison with the cardholder details 
accessible by the authorization server. 

The above embodiments are described by way of example and are not to be 
15 construed as limiting the scope of the invention. Instead, the invention extends to all 
variants which fall within the scope of the following claims. 
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CLAIMS 

1 . A method of processing a data transaction between a terminal (14) and a first server 
(20) over a public network (100) and between the first server (20) and a second server (30), 
comprising: 

transmitting transaction message data (F) and identification data (ID) from said 
terminal (14) to said first server (20); 

transmitting said identification data (ID) from said first server (20) to said second 
server (30); 

comparing said received identification data (ID) at said second server (30) with 
previously stored identification data and generating an authorisation message (ARES) 
indicating the degree of matching between said received identification data (ID) and said 
previously stored identification data; 

transmitting said authorisation message (ARES) from said second server (30) to 
said first server (20): 

and processing said transaction message data (F) at said first server (20) according 
to the received authorisation message (ARES). 

2. A method as claimed in claim 1, wherein said transaction data (F) is processed at 
said first server (20) further according to the content of the transaction data (F). 

3. A method as claimed in claim 2, wherein the processing step comprises: 
determining acceptance criteria from the authorisation message (ARES); 
determining one or more acceptance parameters from the transaction message data 

(F); 

and processing the transaction message data (F) as valid if the one or more 
acceptance parameters meet the acceptance criteria. 

4. A method as claimed in any preceding claim, wherein the identification data (ID) is 
sent to the second server together with transaction identification information (ATC, UN2, 
H) specific to the current transaction, said authorisation response (ARES) also indicating 
whether the transaction identification information (ATC. UN2, H) has been verified. 
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5. A method as claimed in claim 4 r wherein said transaction identification information 
(ATC UN2, H) is generated by said terminal (14) together with a digital signature (MAC) 
which is also sent to the second server (30), and the second server (30) verifies the digital 
signature (MAC) against the transaction identification information (ATC, UN2 ? H). 

6. A method as claimed in any preceding claim, wherein the authorisation message 
(ARES) is signed by the second server (30), and the signed authorisation message (ARES) 
is verified by the first server (20), the processing of the transaction message data (F) being 
dependent on said verification by the first server (20). 

7. A method of processing a data transaction between a terminal (14) and a first server 
(20) over a public network (100) and between the first server (20) and a second server (30), 
comprising: 

generating transaction message data (F) at said terminal (14); 

generating at the terminal ( 1 4) variable terminal identification information (MAC) 
which identifies the terminal (14) and varies for each said data transaction; 

digitally signing said transaction message data (F); 

transmitting said signed transaction message data (SD) and said terminal 
identification information (MAC) from said terminal (14) to said first server (20) over said 
public network (100); 

verifying said transaction message data (F) at said first server (20); 

transmitting said terminal identification information (MAC) from said first server 
(20) to said second server (30); 

verifying said terminal identification information (MAC) at said second server (30) 
and generating a transaction authorisation message (ARES) dependent on the result: 

digitally signing said transaction authorisation message (ARES) at said second 
server (30); 

and transmitting said signed transaction authorisation message (ARES) from said 
second server (30) to said first server (20). 
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8. A method as claimed in claim 7. wherein said step of verifying said transaction 
message data (F) includes verifying the consistency of the transaction message data (F). 

9. A method as claimed in claim 7 or claim 8, wherein said step of verifying said 
transaction message data (F) includes verifying the digital signature of the transaction 
message data at the first server (20). 

1 0. A method as claimed in claim 7 or claim 8, further comprising transmitting said 
signed transaction message data (SD) to said second server (30) and verifying the digital 
signature of said transaction message data (F) at said second server (30). 

11. A method as claimed in any one of claims 7 to 10, wherein said terminal 
identification information (MAC) is digitally signed at the terminal (14). 

12. A method as claimed in claim 11, further comprising verifying the digital signature 
of said terminal identification information (MAC) at said second server (30). 

13. A method as claimed in claim 11. further comprising verifying the digital signature 
of said terminal identification information (MAC) at said first server (20). 

14. A method as claimed in claim 12 or 13, wherein the terminal identification 
information (MAC) is signed and verified using a symmetric key pair. 

15. A method as claimed in any one of claims 7 to 14, including inputting user 
identification information (ID) from a user (12) at said terminal (14), 

wherein the user identification information (ID) is transmitted to said first server 
(20) and from said first server (20) to said second server (30), the method further 
comprising: 

comparing the received user identification information (ID) at said second server 
(30) with previously stored user identification information, the content of the authorisation 
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message (ARES)- being dependent on said comparison of said user identification 
information (ID). 

16. A method as claimed in any one of claims 7 to 15, including supplying information 
5 (ARDEP) derived from said authorisation message (ARES) and said transaction 

identification information (SI) from said first server (20) to data storage means (50). 

17. A method as claimed in any one of claims 7 to 16, wherein said terminal (14) 
includes a removable authentication token (18) from which the terminal identification 

10 information (MAC) is derived, the terminal identification information (MAC) identifying 
the removable authentication token (18). 

18. A method as claimed in any one of claims 7 to 16, wherein said terminal (14) 
includes a removable authentication token (18) from which the digital signature of the 

1 5 transaction message data (F) is derived. 

19. A method as claimed in claim 17 or claim 18, both when dependent on claim 15, 
further comprising, prior to said data transaction: 

verifying the identity of the user (12) and of the token (18) and transmitting a 
20 verification message (V) to the second server (30); and 

storing status information at said second server (30) in response to said verification 
message (V); 

wherein said authorisation message (ARES) is dependent on said status 
information. 

25 

20. A method as claimed in any one of claims 7 to 19, further comprising processing 
said transaction message data (F) at said first server (20) according to the received 
authorisation message (ARES). 

30 21. A method as claimed in claim 20, wherein the processing step comprises: 
determining acceptance criteria from the authorisation message (ARES): 
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determining one or more acceptance parameters from the transaction message data 

(F); 

and processing the transaction message data (F) as valid if the one or more 
acceptance parameters meet the acceptance criteria. 

5 

22. A method as claimed in any preceding claim, wherein said transmissions between 
the first server (20) and the second server (30) are performed over said public network 
(100). 

10 23. A method as claimed in any preceding claim, wherein said public network (100) is 
a packet-switched network. 

24. A method as performed by the first server (20) in a method as claimed in any 
preceding claim. 

15 

25. A method as performed by the second server (30) in a method as claimed in any 
one of claims 1 to 23. 

26. Apparatus arranged to perform the method as claimed in claim 24. 

20 

27. Apparatus arranged to perform the method as claimed in claim 25. 
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